1. Field of the Invention
The present invention relates to an electronic catalog maintenance system for maintaining an electronic catalog formed according to a prescribed standard such as IS013584.
2. Description of the Background Art
IS013584 (Parts Library) is the conventionally known international standard for implementing the electronic catalog system for electronically providing product information on the Internet. In this IS013584, the electronic catalog is formed by dictionary data and contents (catalog data), which are given in a unified data structure in order to realize sharing and reuse of the product information.
In the dictionary data defined by IS013584, the product classification is expressed hierarchically as in an example shown in FIG. 27, by relating “product classes” A0, B0, B1 and C0–C3 by a single tree structure. Each of the “product classes” A0, B0, B1, C0–C3 has “attribute items” V0–V6, and the “attribute items” of one “product class” (such as V0 and V1 belonging to B0, for example) are inherited to the lower “product classes” (C0 and C1).
Also, in IS013584, a unique ID (identifier) called “BSU (Basic Semantic Unit) code” is to be assigned to each one of the “product classes” and the “attribute items” in order to identify it uniquely. Note that the “attribute items” includes “Visible” type attribute items which can only be referred and “Applicable” type attribute items for which actual values can be entered. The “Applicable” type attribute items are to be selected from “Visible” type attribute items that can be referred (V0 of C2, for example).
While IS013584 provides a framework for the electronic catalog, the international standardization of actual dictionary data is also in progress, and IEC61360 is currently striving for the standardization of the upper hierarchy part of the dictionary data in the field of electric and electronic products, that is, the general part regarding the “product classes” and the “attribute items”. As a result, a product catalog producer of each company can creates that company's own contents by determining the original detailed “product classes” and “attribute items” as a lower level development from IEC61360.
A user of the electronic catalog can retrieve a desired product from the contents created in this way by tracing the classification hierarchy of the “product classes” and narrowing down products that can meet his/her needs by referring to attribute values. In recent years, several systems in compliance with IS013584 have been developed in this trend.
In IS013584 described above, a basic idea of the maintenance regarding a dictionary system formed according to the definition is described, and in particular, a mechanism based on Version/Revision updates is described for management of the dictionary.
FIGS. 28A and 28B summarize that basic idea. In FIG. 28A, a way of handling each type is described for addition, change, and deletion of associated information of the attribute item (property). Also, in FIG. 28B, a way of handling each type is described for addition, change, and deletion of associated information of the product class (which will be referred to hereafter as “class”).
However, according to the agreement shown in FIGS. 28A and 28B, changes of the dictionary are very limited, and in particular, changes required in the following cases cannot be handled.
Case 1) Deletion of Visible/Applicable Property
Case 2) Change of Visible/Applicable Property
Case 3) Change which deletes a Property to be inherited, among changes of Super Class
Case 4) Change of Name scope of Visible Property
Note however that, in Case 2), the “Version UP of Property” event is excluded, and addition of Visible/Applicable Property can be handled by Version up.
Note also that, in Case 3), the “Version UP of Super Class” event is excluded, and change which does not delete a Property to be inherited such as insertion of an intermediate class can be handled by Version up, while change of Preferred Name can be handled by Revision up.
Now, it is expected that these Case 1) to Case 4) will occur frequently in practice as in the case of changing the class hierarchy structure. For example, they are expected to occur in the case of newly creating a class (FFF) at an end (EEE) of the tree structure as shown in FIG. 29, the case of deleting an end class (HHH) as shown in FIG. 30, the case of merging a plurality of product classes (EEE and HHH) to one product class (KKK) as shown in FIG. 31, the case of moving the product class (HHH or DDD) as shown in FIGS. 32, 33, 34 and 35, and the case of creating or deleting an intermediate class (HHH) as shown in FIGS. 36 and 37.
Consequently, it is practically very important to enable handling of such cases as Case 1) to Case 4) by going beyond the framework of IS013584. However, the following problems are encountered in realizing this.
First, the BSU code that is once issued and disclosed cannot be deleted and must be permanently managed even when it becomes unused as it is taken out from the dictionary system, because there is a possibility of referencing from the legacy system, so that there is a need to be compatible with the legacy system.
Second, one class or attribute can be regarded as a number of different classes or attributes when the hierarchy structure is changed, even if the definition and the content of that class or attribute as a single entity remain unchanged. This will cause a large number of the new issuance of the BSU code and the releasing of the BSU code so that the management of codes becomes very difficult. For this reason, there is a need to provide a function for comprehending the new issuance of the BSU code.